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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp) . 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ETSI Technical Committee Telecommunications and Internet 
converged Services and Protocols for Advanced Networking (TISPAN). 



Introduction 

The present document describes the main type of IMS based IPTV Customer Devices that take part in Customer 
Premises Network in terms of general architecture and in terms of reference points with the NGN and CNG. 
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1 Scope 

The present document defines the stage 2 Customer Network Devices for IPTV services (IPTV-CND) specifications. It 
is therefore addressing the overall architecture of the customer network device (CND) enabling the IPTV service 
consumption. The architectural definition is covering both transport and service layer related functionalities. The 
reference points between the CND and the Customer Network Gateway (CNG) are also part of the specifications. 

The 2 solutions elaborated specified in TS 182 027 [2] and TS 182 028 [4] are IMS based IPTV and IPTV Dedicated 
Subsystem solutions but only the IMS based IPTV solution is considered in the present document. 

2 References 

References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• Non-specific reference may be made only to a complete document or a part thereof and only in the following 
cases: 

if it is accepted that it will be possible to use all future changes of the referenced document for the 
purposes of the referring document; 

for informative references. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http ://docbox . etsi . or g/Ref erence . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are indispensable for the application of the present document. For dated 
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document 
(including any amendments) applies. 

[1] ETSI TS 181 016: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); Service Layer Requirements to integrate NGN services and 
IPTV". 

[2] ETSI TS 182 027: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); IPTV Architecture; IPTV functions supported by the IMS 
subsystem" . 

[3] ETSI TS 183 063: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); IMS-based IPTV stage 3 specification". 

[4] ETSI TS 182 028: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); IPTV Architecture; Dedicated subsystem for IPTV functions". 

[5] ETSI TS 183 064: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); Dedicated IPTV subsystem stage 3 specification". 

[6] ETSI TS 185 003: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); Customer Network Gateway Architecture and Reference 
Points". 
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[7] ETSI TS 185 006: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); Customer Devices architecture and interfaces and Reference 
Points". 

[8] ETSI ES 282 001: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); NGN Functional Architecture". 

[9] ETSI TS 181 005: "Telecommunications and Internet Converged Services and Protocols for 

Advanced Networking (TISPAN); Service and Capability Requirements". 

2.2 Informative references 

The following referenced documents are not essential to the use of the present document but they assist the user with 
regard to a particular subject area. For non-specific references, the latest version of the referenced document (including 
any amendments) applies. 

[i.l] ETSI TR 185 004: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); High level customer network architectures". 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

Customer Network Device (CND): physical device enabling service(s) usage 

NOTE: CNDs can be dedicated to the internet, conversational and audio-video services, but they could be also 
Consumer Electronics equipment and other devices which may have nothing to do with these premium 
services (e.g. services performing a content sharing within a CPN, typically between a PC and a music 
system, through the CNG). 

Customer Network Gateway (CNG): gateway between the Customer Premises Network (CPN) and the Access 
Network able to perform networking functions from physical connection to bridging and routing capabilities, but also 
possibly implementing functions related to the service support 

Customer Premises Network (CPN): in-house network composed by customer network gateway, customer network 
devices, network segments (physical wired or wireless connections between customer network elements), network 
adapters (performing a L1/L2 conversion between different network segments) and nodes (network adapters with L3 
routing capabilities) 

IPTV services Customer Network Device (IPTV-CND): physical device enabling consumption of IPTV service(s) 

NOTE: IPTV-CNDs are dedicated to the TV like audio-visual services such as live TV or On demand. 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

ACE Access Configuration Function 

AtF Attachment Function 

B2BUA Back-to-Back User Agent 

BC Broadcast 

BF Browser Function 

BTA Broadcast TV Application 

C-BGF Core Border Gateway Function 

CDA CoD AppHcation 

CF Configuration Function 

CMF Configuration and Maintenance Function 
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CMM Configuration Management and Monitoring 

CND Customer Network Device 

CNG Customer Network Gateway 

CNGCF Customer Network Gateway Configuration Function 

COD Content On Demand 

CPA Client PVR Application 

CPN Customer Premises Network 

cPVR client PVR 

DHCP Dynamic Host Configuration Protocol 

DLNA Digital Living Network Alliance 

EPG Electronic Programme Guide 

ESG Electronic Service Guide 

IGMP Internet Group Management Protocol 

IMS IP Multimedia Subsystem 

IPTV Internal Protocol Television 

IPTVF IPTV Function 

LAF Local Authentication Function 

MD Media Delivery 

MDA MetaData Application 

MDF Media Delivery Function 

MDP MetaData Processing 

MPC Media Player Control 

MPPF Media Packet Processing Function 

NACF Network Access Configuration Function 

NAPT Network Address and Port Translation 

NAT Network Address Translation 

NGN Next Generation Network 

NPA N-PVR Application 

NPVR Network Personal Video recorder 

NTF NAPT Traversal Function 

PCF Policy Control Function 

P-CSCF Proxy Call Session Control Function 

PPF Plug and Play Function 

PVR Personal Video Recorder 

QoE Quality of Experience 

QoS Quality of Service 

RTP Real Time Protocol 

RTSP Real Time Streaming Protocol 

SCF Session Control Function 

SDF Service Discovery Function 

SIP Session Initiation Protocol 

SPA Service Profile Application 

SPM Service Profile Management 

SSF Service Selection Function 

STB Set Top Box 

UA User Agent 

UE User Equipment 

UPnP Universal Plug and Play 

VOD Video On Demand 
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4 High level functional architecture for IPTV-CNDs 

The high level functional architecture of IPTV-CND is composed of 3 layers as represented in figure 4.1. 



4.1 Architecture layers 



CND 



Application & User Experience Layer 



Service Layer 



Transport Layer 



Figure 4.1 : Architecture layers 



4.1.1 Transport layer 



This layer comprises functional entities that provide relevant IPTV transport level functions such as network attachment 
and media processing and streaming functions. 

4.1.2 Service layer 

This layer comprises functional entities that provide relevant IPTV functionality to applications above and also include 
entities that are used for management and control of platform itself. Depending on the type of services, the service layer 
entity must communicate either with other devices in the customer network or the external network using the transport 
layer. Service layer entities do not have a direct user interface and may be controlled via appropriate applications layer 
entities. 

Examples include: 

• Media Management function. 

• Service Discovery function. 

• Platform security function. 

• CA/DRM function. 
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• Configuration and Management function, etc. 

4.1 .3 Application and User Experience layer 

This layer comprises IPTV applications that have user interface (user driven input and /or output) and use the services 
provided by the underlying Service Layer to drive end user experience. 

Examples of applications include: 

• VOD. 

• Broadcast TV. 

• IPTV Service Guide interface, etc. 

The user may be a customer or a service operator. 

For the service operator, these functions may include service specific functions such as measurement applications 
(e.g. user satisfaction). 



4.2 IPTV operating modes 



IPTV CNDs can be simple terminals connected to the NGN or be part of a CPN in connection with the CNG. Different 
configuration are discussed in TR 185 004 [i.l]. Consequently, the IPTV CND can work in different modes in relation 
with the CNG. 

• Bridged mode: In this mode, the IPTV CND is working in compliance with TS 183 063 [3] and is connected 
to the NGN network or connects to the NGN via a CNG operating in bridged mode. In bridged mode of 
operation, the CNG provides only L1-L2 functionality. The CND connects over G^^ to the NGN. 

• Routed mode: In this mode, the IPTV CND connects to the NGN via a CNG operating in routed mode and is 
capable to interact with other devices in the CPN with other protocols above L3. In routed mode of operation, 
the CNG includes routing and service layer functionality as well (L3 and above). The routed mode shall be 
related to an authentication session. A session operating in one of the following routed modes can only operate 
in one of them at the same time: 

NGN mode: IPTV CND connects directly to the NGN through the CNG over G^^. The CNG-PCF and 
CNG-NFF as defined in ETSI TS 185 003 [6] may perform functionality such as NAPT and CNG 
internal QoS. 

CPN mode: IPTV CND connects to the NGN through CNG over G^^,. The CNG-SIP Proxy B2BUA, 

CNG-ACF, CNG-PCF as defined in TS 185 003 [6] may perform functionality such as NAT/FW 
traversal, CNG internal QoS or IETF SIP to IMS SIP conversion. 

• Intra CPN mode: At service layer, the 2 devices interact with or without the support of the CNG. 

NOTE: Specifications for the intra CPN mode are not part of the present document but in this case, for example, 
IPTV CND could follow DLNA (Digital Living Network Alliance) interoperability guidelines. 



5 IPTV Customer Network Device Architecture 

The present document categorizes IPTV-CNDs into two types depending on TISPAN IPTV solutions that have been 
developed by WG2. They are: 

• Devices compatible with the IPTV dedicated subsystem solution. 

• Devices compatible with the IMS based IPTV solution. 
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Devices compatible with IPTV dedicated subsystem solution: 

This category of IPTV CNDs includes IPTV capable device which can be utilized in conjunction with IPTV services 
delivered in compHance with TS 182 028 [4] and TS 183 064 [5]. 

Devices compatible with the IMS based IPTV solution: 

This category of IPTV CNDs includes IPTV capable device which can be utilized in conjunction with IPTV services 
delivered in compliance with TS 182 027 [2] for "IPTV functions supported by the IMS subsystem" for the architecture 
aspects and TS 183 063 [3] for protocols aspects. 

Only IMS based IPTV compatible devices are considered for detailed description in the present document. 

5.1 IMS based IPTV compatible devices 

IMS based IPTV compatible means compliance with TS 182 027 [2]. 



5.1.1 



Detailed Architecture 
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Figure 5.1 : Detailed IPTV CND architecture 

NOTE: Entities in a given layer are interfacing/interacting with one or more functional entities in layers below it 
in order to accomplish the given function. Figure 5.1 does not depict all these internal 
interfaces/interactions which are implementation specific. 
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5.1 .1 .1 Transport Layer Functions 

5.1 .1 .1 .1 Network attachment functions 

IPTV CND attachment functions are compliant with the specifications for CNDs TS 185 006 [7]. They include: 

• IPTV-CND-CMF: Customer Network Device - Configuration and Maintenance Function. 

• IPTV-CND-AtF: Customer Network Attachment Function. 

• IPTV-CND-LAF: Customer Network Device - Local Authentication Function. 

5.1 .1 .1 .2 Transfer functions 

IPTV CND transfer functions are compliant with the specifications for CNDs TS 185 006 [7]. 

• IPTV-CND-NTF: NAPT Traversal Function. 

5.1 .1 .1 .3 Transport functions 

5.1 .1 .1 .3.1 IPTV-CND-MPPF: IPTV Customer Network Device-Media Packet Processing Function 

The MPPF is the termination point for media flows encrypted or not encrypted, over the D- interface connecting the UE 
to the NGN C-BGF as defined in ES 282 001 [8]. 

NOTE 1 : The handling of encrypted media flows is out of scope of this release. 

NOTE 2: This function is providing support for NAT traversal such as the media port punching mechanisms and 
also for the usage of IGMPv3. 

5.1 .1 .1 .3.2 IPTV-CND-QOS: IPTV Customer Network Device-QoS Function 
The IPTV CND should support the following set of QoS functions for egress traffic: 

1) Traffic classification based on rules defined by the NGN service provider, access network provider or 
connectivity provider (business role definitions are defined in TS 181 005 [9]). 

2) Packet marking based on the different service classes. 

5.1 .1 .2 Service layer functions 

NOTE: The security aspects are not specified in this release. The term security is to be taken here in a general 
sense covering several aspects including content protection, conditional access, privacy and parental 
control. 

5.1 .1 .2.1 IPTV-CND-SIP UA: IPTV Customer Network Device SIP UA 

This block implements the G^^, G^^. interfaces on IPTV CND compatible with the IMS based IPTV solution. This SIP 
UA shall perform the service authentication and manage signalling flows securely following in that what is already 
described in clause 6 on Authentication in TS 185 006 [7]. 

5.1 .1 .2.2 IPTV-CND-SPM: IPTV Service Profile Management function 

This block implements the U^ interface; the U^ enables the access to an Application Sever to support the user in 
configuration services update. 

5.1 .1 .2.3 IPTV-CND-MDP: IPTV Customer Network Device MetaData Processing 

This functional entity utilizes X^, G^^ and/or X^ to receive service related metadata (e.g. IPTV services plans, EPG, 
VOD catalogue, customer applications). 
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5.1 .1 .2.4 IPTV-CND-MPC: IPTV Customer Network Device Media Player Control 

This functional entity utilizes X^ for control of media delivery (e.g. RTSP set up, Play, stop, etc.). 

5.1 .1 .2.5 IPTV-CND-MD: IPTV Customer Network Media Delivery 

This functional entity implements the X^ interface for the media streaming (e.g. RTF streams). 



5.1.1.2.6 



IPTV-CND-CMM: Configuration Management and Monitoring 



This function provides support for the IPTV-CND-CMF for service layer configuration, middleware management, 
performance monitoring (providing feedback on QoS/QoE including packet losses, packet delay and delay jitter, frame 
loss, pixilation) and diagnostics through the e^ reference point and e3' reference point. 



5.1.1.2.7 



IPTV-CND-PPF: IPTV Customer Network Device - Plug and Play Function 



The CND-PPF in the CNG may exchange some device information (discovery, description) with other devices and 
allow their control. Particularly, the entity should allow a communication between many types of Customer Device 
within the CPN, based for instance on UPnP. 

Additional functions may be present in the CNG and the IPTV CND to support multi service providers capabilities as 
well as local communications between the different devices of the CPN, including the CNG. 

The functions supporting these capabilities are already defined in: 

• TS 185 003 [6] as the CNG-PPF (CNG - Plug and Play function). 

• TS 185 006 [7] as the CND-PPF (Customer Network Device - Plug and Play function). 

• IPTV-CND-PPF: IPTV CND Plug and Play function. 
And the related reference point defined in: 

• TS 185 006 [7] Reference point C. 





IPTV CND 




c 




CNG 








CNG-PPF 

(Plug and Play 
Function) 






IPTV CND - PPF 

(Plug and Play 
Function) 




^ 





















Figure 5.2: Reference point C between CNG and IPTV CND 

Specific definitions of these functions for IPTV services are described hereafter. 

Role of IPTV CND Plug and Play function: collect and deliver information related to: 

• Content availability and description: There can be different format utilized in the CPN to represent these data. 
The Plug and Play function may include capabilities for converting data format. 

• Local user identity and related rules for content access: there may be local identity utilized only in the CPN. 
The Plug and Play function may include capabilities for managing local identities with IMS domain customer 
identities. 
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• User interactivity related data to get control over resources and content selection and playing. Presentation data 
supporting user interactivity can be in different format. The Plug and Play function may include capabilities 
for adaptation of these data format. 

• Aggregation of content description data: content can be provided from outside by different service providers or 
can be stored locally. 

5.1 .1 .2.8 IPTV-CND-cPVR: IPTV client PVR Function 

This functional entity has a normal PVR's capabilities, i.e. it records linear TV program and plays the recorded TV 
program; in addition, it provides also time- shift capability. 

The interface between IPTV application cPVR and the cPVR function is internal; therefore it can be proprietary. 

5.1 .1 .3 Applications and user experience layer functions 

The functions in this layer may be supported directly on the CND by native applications or they may be executed in a 
browser-based environment. Both types of applications may coexist on the CND implementing a hybrid concept. 

5.1.1.3.1 IPTV Applications 

The IPTV Applications provide support for a variety of IPTV Services and functions. They include: 

5.1 .1 .3.1 .1 IPTV-CND-CDA: The CoD Application 

This application function allows a user to select and control playback of a CoD stream. 

5.1 .1 .3.1 .2 IPTV-CND-BTA: Broadcast TV Application 

This application function allows a user to select a broadcast channel to view live/broadcast IPTV content. 

5.1 .1 .3.1 .3 IPTV-CND-NPA: N-PVR Application 

This application function allows users to schedule N-PVR capture requests. 

5.1 .1 .3.1 .4 IPTV-CND-CPA: Client PVR Application 

This application function allows end-users to schedule client PVR for recording TV program and playing the recorded 
TV program and time- shift TV. 

5.1 .1 .3.2 IPTV-CND-SPA: Service Profile Application 

This application function allows users to manage IPTV service profile information. 

5.1 .1 .3.3 IPTV-CND-MDA: MetaData Application 

This functional entity enables the user to exchange service selection data/metadata (using the IPTV-CND-MDP) that 
enriches IPTV service experience and may be exchanged with the SSF (EPG guide, CoD catalogue, etc.), MDF or the 
SCF. 

Implementations of the IPTV-CND-MDA shall contain: 

• EPG services as required inTS181016[l]. 
Implementations of the IPTV-CND-MDA may contain: 

• ESG services as required inTS181016[l]. 

• Instant messaging services as required inTS181016[l]. 

• Context aware messaging services (e.g. content recommendations) as required in TS 181 016 [1]. 
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5.1 .1 .3.4 IPTV-CND-BF: Browser Function 

The Browser Function (BF) loads web based IPTV Application (for example, COD, Broadcast TV and NPVR) from the 
Service Selection Function (SSF) via the Xa reference point defined in TS 182 027 [2]. 

It should be able to run IPTV applications (web based) for presentation of user interface and including scripting support 
for interaction at the underlying service layer functions (e.g. Media Player Control and Media Delivery, Metadata 
Processing, etc.). 

For example an application that runs in the BF can query (internally to the IPTV-CND at the Metadata Processing 
Function) the Metadata-based Content Guide in order to extract any data it may contain. 



6 Reference points 

6.1 Reference points for IMS based IPTV compatible devices 
6.1 .1 Transport layer Reference points 

6.1 .1 .1 Transport Reference points 

D-: This reference point is used to carry all data between the UE and the access point in the NGN. As such, in the case 
of IPTV CND, the D- reference point is used to send and receive media data and media control flows to/from the NGN 
as specified in TS 182 027 [2]. The Dj reference point complies with the ES 282 001 [8] specifications. 

Dm: The D-. reference point is responsible for the exchange of media flows between the IPTV CND and the CNG. It is 
applicable only in case the CNG is supporting IPTV in routed mode, as specified in the present document. Through D-., 
the IPTV CND communicates with the CNG-IPTVF and its related functionalities (IGMP proxy and snooping). 

This reference point is mandatory for IPTV CNDs performing CoD service (using RTSP) and BC service (using 
IGMP). 

6.1 .1 .2 Network attachment Reference points 

e^: This reference point between the IPTV-CND and NACF is used by the IPTV CND for attaching itself to the IMS 
IPTV service provider network. The usage of the e^ reference point conforms to TS 185 006 [7]. 

Cj.: This reference point between the IPTV CND and CNG (in "routed mode") provides network attachment functions 
and conforms to TS 185 006 [7]. 

63: This reference point between IPTV-CND and CNGCF is used to remotely configure and manage the IPTV CND. 
The usage of the e^ reference point conforms to TS 185 006 [7]. 

63.: This reference point between the IPTV CND and CNG (in "routed mode") provides device configuration functions 
and conforms to TS 185 006 [7]. 



6.1 .2 Service layer Reference points 



C: This reference point is between the Plug and Play function in the IPTV CND and the CNG-PPF in accordance with 
definition given in TS 185 006 [7] and TS 185 003 [6]. This reference point is optional and is used only in the Routed 
NGN mode and the Routed CRN mode. In these modes, the reference point C allows the establishing of a relationship 
between the CPN resources and the NGN; this relationship is based on exchange of information between CNDs and 
possibly the CNG in the CPN. 

G^: This reference point between the IPTV CND and the NGN (P-CSCF) and conforms to TS 185 006 [7]. 
G^.: This reference point between the IPTV CND and CNG conforms to TS 185 006 [7]. 
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X^: This logical end-to-end reference point between the IPTV-CND and IPTV Media Control Function is used for 
carrying media control messages. The usage of the X^ reference points conforms to TS 182 027 [2]. 

X^: This logical end-to-end reference point between the IPTV-CND and IPTV Media Delivery Function is used for 
carrying the actual media. The usage of the X^ reference points conforms to TS 1 82 027 [2] . 

X^: This reference point between IPTV-CND and SSF is used by the IPTV-CND to make appropriate service 
selections. 

U^: This reference point between the IPTV-CND and IPTV Service Control is used for IPTV user profile configuration 
and conforms to TS 182 027 [2]. 

NOTE: The X^, reference point between IPTV-CND and SDF used by the IPTV-CND to make appropriate 

service attachment is a non mandatory reference point defined in an informative annex of TS 182 027 [2] 
and is for further study. 



7 The IPTV - CND Data Model 

The IPTV CND shall support the device data model for remote management as proposed by DSL Forum, the TR135 
model for STB published December 2007. 

Additionally, any relevant TR135 object extensions specified in TS 183 063 [3] required to support IPTV Service 
Provider/SDF Discovery as per "TR-069 Based SDF Discovery procedures" should be supported. 



8 Deployment's scenarios 



In the CPN the IPTV service can be provided in at least two deployment's scenario. Below are two such options 
provided: 

• Option 1: All IPTV functionalities are implemented in the IPTV-CND. 

• Option 2: Some IPTV functionalities are implemented in the IPTV-CND and the others in the CNG. 



8.1 Option 1 



In the deployment's scenario "Option 1" all functionalities described in the present document are implemented in the 
IPTV-CND. 



8.2 Option 2 



In the deployment's scenario "option 2", according to TS 185 003 [6], a subset of functionalities described in the present 
document are implemented in the IPTV-CND. 

Table 8.1 lists the functionalities that are implemented on the CNG and on the IPTV-CND. 

Table 8.1 : Deployment's scenario "option 2" 



Layer 


Function 


CNG 


IPTV-CND 


Transport 


Network Attachment: 

CMF- Configuration and IVIaintenance 

>AfF- Attachment 

LAF- Local Authentication 


X 


X 


Transfer : 

NTF- NAPT Traversal 


X 




MPPF- Media Packet Processing Function 




X 


QoS- QoS Function 


X 


X 


IPTV Function (IGMP proxy, snooping, etc.) 


X 
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Layer 


Function 


CNG 


IPTV-CND 


Service 


SIPUA 


X 




SPM- Service Profile Management 




X 


MDP- Metadata Processing 


X 


X 


MPC- Media Player Control 




X 


MD- Media Delivery 




X 


CMM- Configuration Management and Monitoring 


X 


X 


CF (PPF) - Plug&Play Function 


X 


X 


Sec- Security Function 




X 


Application 


IPTV Application: 
IPTV-CND-CDA - CoD Appl. 
IPTV-CND-BTA - Broadcast TV Appl. 
IPTV-CND-NPA - N-PVR Appl. 
IPTV-CND-CPA - client PVR Appl. 




X 


SPA - Service Profile Appl. 




X 


IVIDA - Metadata Appl. 




X 


/Pr\/-CA/D-eF Browser Function 




X 


NOTE: X: means where (CNG or IPTV-CND) the functionality should be implemented, if it is present. 



The option 2 allows the IPTV-CND to use some functions present in CNG, e.g. SIP-UA, according to TS 185 003 [6]. 



9 Information Flows 

NOTE: Information flows clause is non normative text reported in form of examples to better understand the 
relationships between the IPTV CND and the NGN, the CNG and other CNDs. 

The list of flows given hereafter is not exhaustive. 



9.1 



Information flows between IPTV-CND and NGN 



9.1 .1 Example message flows on Xa 















IPTV-CND-MDP 




NGN-SSF 








(1) HTTP GET 




^ 








(2) 200 OK 















Figure 9.1 : Message flows for service selection 

The message flow in figure 9.1 is an example of service selection function. 

With the HTTP GET, the CND asks the NGN for the program information, such as CoD catalogue, BC channels. And 
NGN returns the program information to the CND. 

This procedure example for service selection using HTTP is compliant with TS 183 063 [3]. 

This procedure example is applicable for the IPTV-CND in the bridged mode. 
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9.1 .2 Example message flows on Ut 















IPTV-CND-SPM 




NGN-SCF 








(1) HTTP GET 




^ 








(2) 200 OK 




(3) HTTP PUT 


(4) 200 OK 






^ 







Figure 9.2: Message flows for service related information configuration 

The message flow in figure 9.2 is an example of service related information configuration function. 

With HTTP GET and PUT methods, the CND retrieves and modifies its service related information. 

The procedure example for service related information configuration using HTTP is compliant with TS 183 063 [3]. 

This procedure example is applicable for the IPTV-CND in the bridged mode. 

9.1 .3 Example message flows on Gm 

9.1.3.1 Registration 

The NGN registration flows are compliant with TS 183 063 [3]. 

9.1 .3.2 Session Initiation and Termination 

The Session Initiation and Termination flows are compliant with TS 183 063 [3]. 

9.1 .3.3 IPTV Service Action Data Delivery 

The IPTV service action data delivery flows are compliant with TS 183 063 [3]. 















IPTV-CND-SIP UA 




NGN-P-CSCF 








(1) SIP INFO 


r MESSAGE 


^ 








(2) 200 OK 















Figure 9.3: Message flows for IPTV service action data delivery 

IPTV service action data, such as BC bookmarks, Available CoD and NPVR items, are delivered to CNG-SIP via SIP 
INFO or MESSAGE method. 
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This procedure example for service action data delivery is compliant with TS 183 063 [3]. 
This procedure example is applicable for the IPTV-CND in the bridged mode. 

9.1 .4 Example message flows on X^ and Xd 

IPTV application utilizes X^ for media control, such as RTSP setup, play, teardown, and utilizes X^ for media 
streaming, such as RTF stream. 



9.1.4.1 



Message flows for CoD service 



IPTV-CND-MPC 



MF 



(1) RTSP SETUP 



(2) 200 OK 



(3) RTSP PLAY 



(4) 200 OK 



(5) RTP/RTCP 



< 



> 



(6) RTSP TEARDOWN 



(7) 200 OK 



Figure 9.4: Information flows for media content control and delivery 

This procedure example for media control using RTSP is compliant with TS 183 063 [3]. 
This procedure example is applicable for the IPTV-CND in the bridged mode. 

9.1 .4.2 Message flows for BC service 















IPTV-CND-MPC 




MF 








(1) Join Multicast G] 


roup 










(2) RTP/RTCP 


i^ 




< 


> 


(2) Leave Multicast Group 


l^ 

^ 













Figure 9.5: Information flows for media content control and delivery 
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This procedure example for media streaming using IGMP is compliant with TS 183 063 [3]. 
This procedure example is applicable for the IPTV-CND in the bridged mode. 

9.1 .5 Example message flows on 03 















IPTV-CND-CfM 




CNGCF 








(1) HTTP GET 




^ 








W 

(2) 200 OK 








^ 







Figure 9.6: Message flows for configuration and management 

IPTV applications utilize ^^ for auto-configuration, software management and diagnostics. 
This procedure example is applicable for the IPTV-CND in the bridged mode. 

9.1 .6 Example message flows on ei 



IPTV-CND-AtF 



ARF, NACF 



(1) DHCPDISCOVER 



(2) DHCPOFFER 



(3) DHCPREQUEST 



(4) DHCPACK 



(5) DHCPRELEASE 



Figure 9.7: Message flows for network attachment 

1) The CND broadcasts a DHCPDISCOVER message with its client identifier and some request parameters, such 
as Domain name and P-CSCF address, etc. 

2) Multiple DHCP servers return DHCPOFFERs with parameters to the CND. 

3) The CND choose one DHCPOFFER, and broadcasts DHCPREQUEST message with configuration 
parameters. 

4) The DHCP server selected in the DHCPREQUEST message commits the binding and responds with a 
DHCPACK message containing the configuration parameters for the CND. 

5) The CND receives the DHCPACK message with configuration parameters. At this point, it is configured. The 
CND may choose to relinquish its lease on a network address by sending a DHCPRELEASE message to the 
server. 
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The client identifier is unique within its subnet. It may contain a hardware address. For a UPnP device, a unique device 
name can be chosen as its cHent identifier. 

This procedure example is applicable for the IPTV-CND in the bridged mode. 



9.2 



Information flows between IPTV-CND and CNG 



9.2.1 Example message flows on C 

In UPnP environment, the control point can retrieve the information of device of interest. The information includes the 
device description and service description describing the capabilities exposed by the device. After getting this 
information, control point sends suitable control message to perform control action. 

This following message flow gives an example of device information exchange and device control based on UPnP 
enabled devices. 



9.2.1.1 



Message flows for device and service information exchange 



The information includes the device description and service description describing the capabilities exposed by the 
device. Two cases are shown in Figures 9.8(a) and 9.8(b) respectively. 















IPTV-CND-PPF 




CNG-PPF 








(1) NOTIFY 












(2) HTTP GET 




(3) Response 


(4) HTTP GET 


(5) Response 













Figure 9.8(a): Message flows for device information exchange based on UPnP 

In figure 9.8(a): 

1) When the CNG is added to the network, it multicasts a number of discovery message advertising itself. The 
interested control point IPTV-CND can listen to the standard multicast address for notifications that new 
capabilities are available. 

2) IPTV-CND retrieves the device description of the CNG by issuing an HTTP GET request to the URL in the 
NOTIFY request from the CNG. 

3) The CNG returns its device description in the body of the HTTP response. 

4) The IPTV-CND retrieves the service description of the CNG by issuing an HTTP GET request to the URL in 
the device description of the CNG. 

5) The CNG returns description of the service description in the body of the HTTP response. 
This procedure example is applicable for the IPTV-CND in the routed mode. 
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IPTV-CND-PPF 




CNG-PPF 








(1) M-SEARCH 




^ 








(2) Response 




(3) HTTP GET 


(4) Response 


(5) HTTP GET 


(6) Response 






^ 







Figure 9.8(b): Message flows for device information excliange based on UPnP 

In figure 9.8(b): 

1) When the IPTV-CND is added to the network, it multicasts a discovery message searching for interesting 
devices. 

2) The CNG Hstens to the standard multicast address for these messages and finds itself matching the search 
criteria in the discovery message. The CNG responds with its unique service name and location. 

3), 4), 5), 6) are similar to 2), 3), 4), 5) in figure 8.8(a) respectively. 

This procedure example is applicable for the IPTV-CND in the routed mode. 

9.2.1 .2 Message flows for device control 















IPTV-CND-PPF 




CNG-PPF 








(1) POST 




^ 








W 

(2) Response 















Figure 9.9: Message flows for device control based on UPnP 

The capabilities exposed by CNG are various, such as QoS provisioning, local user identity, etc. clause 6.1.3 gives the 
details. All these capabilities can be defined in its service description and be performed by sending control message 
using SOAP. 

1) IPTV-CND-PPF invokes a POST request to the CNG-PPF and waits for the response. The SOAP message 
containing the value of input parameters is embedded in the HTTP request. 

2) The CNG-PPF performs the requested control action and returns the response with SOAP message embedded 
to the IPTV-CND-PPF. 

This procedure example is applicable for the IPTV-CND in the routed mode. 
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9.2.2 Example message flows on G 



m' 



9.2.2.1 Registration 

The NGN registration flow is compliant with the specifications for CNDs TS 185 006 [7] in clause 8.3.1. 

9.2.2.2 IPTV Service Action Data Delivery 















IPTV-CND-SIP UA 




CNG-SIP 








(1) SIP INFO 


r MESSAGE 


^. 








(2) 200 OK 








^ 







Figure 9.10: Message flows for IPTV service action data delivery 

IPTV service action data, such as BC bookmarks, Available CoD and NPVR items, are delivered to CNG-SIP via SIP 
INFO or MESSAGE method. 

The procedure example for service action data delivery is compliant with TS 183 063 [3]. 

This procedure example is applicable for the IPTV-CND in the routed CPN mode. 

9.2.3 Example message flows on ev 

The message flows on e^. are compliant with the specifications for CNDs TS 185 006 [7] in clause 8.1. 

9.2.4 Example message flows on 03- 

The message flows on e3. are compliant with the specifications for CNDs TS 185 006 [7] in clause 8.2. 

9.2.5 Example message flows on ay 



IPTV-CND-LAF 



CNG-AuF 



(1) Request for CPN connection 



< 



(2) Authentication procedure 



> 



Figure 9.1 1 : Information flows for IPTV CND connecting to CPN 

This procedure example is applicable for the IPTV-CND in the routed mode. 
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